Fix: Make WASAPI loopback buffer size adaptive to device capabilities#344
Fix: Make WASAPI loopback buffer size adaptive to device capabilities#344anshul23102 wants to merge 1 commit into
Conversation
The WASAPI loopback buffer was using a fixed size that could be incompatible with high-performance audio devices. This caused audio stuttering and irregular visualization spikes on systems with low-latency hardware. Now the buffer duration is determined dynamically based on the device's minimum supported period, with a minimum floor of 10ms to ensure compatibility across different hardware setups. Fixes SamXop123#331 Signed-off-by: Anshul Jain <aj.ts1758@gmail.com>
|
@anshul23102 is attempting to deploy a commit to the Dot_NotSam's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@SamXop123 /assign /claim I've assigned this issue to myself and claimed it as part of GSSoC 2026. Please apply the This PR addresses the WASAPI loopback buffer size limitation that was causing audio stuttering on high-performance systems by making the buffer duration adaptive to the device's capabilities. |
📝 WalkthroughWalkthroughWASAPI loopback capture now queries the device period and initializes its shared-mode audio buffer using the larger of that period or 10ms, while retaining zero periodicity. ChangesWASAPI loopback capture
Estimated code review effort: 2 (Simple) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
SamXop123
added
good first issue
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
audio-helper/Program.cs (1)
126-127: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider discarding the unused
defaultPeriod.
defaultPeriodis captured viaout varbut never read. Using a discard (out _) clarifies intent and avoids a dangling variable.♻️ Optional cleanup
- Marshal.ThrowExceptionForHR(_audioClient.GetDevicePeriod(out var defaultPeriod, out var minimumPeriod)); + Marshal.ThrowExceptionForHR(_audioClient.GetDevicePeriod(out _, out var minimumPeriod));🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@audio-helper/Program.cs` around lines 126 - 127, Replace the unused defaultPeriod variable in the _audioClient.GetDevicePeriod call with a discard (out _) while preserving minimumPeriod for the bufferDuration calculation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@audio-helper/Program.cs`:
- Around line 126-127: Replace the unused defaultPeriod variable in the
_audioClient.GetDevicePeriod call with a discard (out _) while preserving
minimumPeriod for the bufferDuration calculation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 926e182f-8ac1-42a2-afb2-119583f1fdab
📒 Files selected for processing (1)
audio-helper/Program.cs
2 participants
Summary
Fixes the WASAPI loopback buffer being hardcoded to a fixed size that's incompatible with high-performance audio devices. The buffer duration is now dynamically determined based on the device's minimum supported period with a 10ms floor.
Changes
WasapiLoopbackCaptureconstructor to query device period capabilities viaGetDevicePeriodMath.Max(minimumPeriod, 10ms)to adapt to hardware capabilitiesAudioClient.Initializeinstead of fixed 0Testing
Verified on high-performance audio interfaces that visualization no longer exhibits stuttering artifacts. The buffer now respects device latency constraints while maintaining compatibility across different hardware setups.
Related
Closes #331
Summary by CodeRabbit